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OSPFv3 Autoconfiguration 


Abstract 


OSPFv3 is a candidate for deployments in environments where 
autoconfiguration is a requirement. One such environment is the IPv6 
home network where users expect to simply plug in a router and have 
it automatically use OSPFv3 for intra-domain routing. This document 
describes the necessary mechanisms for OSPFv3 to be self-configuring. 
This document updates RFC 5340 by relaxing the HelloInterval/ 
RouterDeadInterval checking during OSPFv3 adjacency formation and 
adding hysteresis to the update of self-originated Link State 
Advertisements (LSAs). 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7503. 
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1. Introduction 


OSPFv3 [OSPFV3] is a candidate for deployments in environments where 
autoconfiguration is a requirement. This document describes 
extensions to OSPFv3 to enable it to operate in these environments. 
In this mode of operation, the protocol is largely unchanged from the 
base OSPFv3 protocol specification [OSPFV3]. Since the goals of 
autoconfiguration and security can be conflicting, operators and 
network administrators should carefully consider their security 
requirements before deploying the solution described in this 
document. Refer to Section 8 for more information. 


The following aspects of OSPFv3 autoconfiguration are described in 
this document: 


1. Default OSPFv3 Configuration 

2. HelloInterval/RouterDeadInterval Flexibility 

3. OSPEFv3 Minimal Authentication Configuration 

4. Unique OSPFv3 Router ID Generation 

5. OSPFv3 Adjacency Formation 

6. Duplicate OSPFv3 Router ID Resolution 

7. Self-Originated LSA Processing 

OSPFv3 [OSPFV3] is updated by allowing OSPFv3 adjacencies to be 
formed between OSPFv3 routers with differing HelloIntervals or 
RouterDeadIntervals (refer to Section 3). Additionally, hysteresis 
has been added to the processing of stale self-originated LSAs to 
mitigate the flooding overhead created by an OSPFv3 Router with a 


duplicate OSPFv3 Router ID in the OSPFv3 routing domain (refer to 
Section 7.4). Both updates are fully backward compatible. 


1.1. Requirements Notation 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 


"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC-KEYWORDS]. 
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2. OSPFv3 Default Configuration 


For complete autoconfiguration, OSPFv3 will need to choose suitable 
configuration defaults. These include: 


1. Area 0 Only — All autoconfigured OSPFv3 interfaces MUST be in 
area 0. 


2. OSPFv3 SHOULD be autoconfigured on all IPv6-capable interfaces on 
the router. An interface MAY be excluded if it is clear that 
running OSPFv3 on the interface is not required. For example, if 
manual configuration or another condition indicates that an 
interface is connected to an Internet Service Provider (ISP), 
there is typically no need to employ OSPFv3. In fact, [IPv6-CPE] 
specifically requires that IPv6 Customer Premise Equipment (CPE) 
routers not initiate any dynamic routing protocol by default on 
the router’s WAN, i.e., ISP-facing, interface. In home 
networking environments, an interface where no OSPFv3 neighbors 
are found, but a DHCP IPv6 prefix can be acquired, may be 
considered an ISP-facing interface, and running OSPFv3 is 
unnecessary. 


3. OSPFv3 interfaces will be autoconfigured to an interface type 
corresponding to their Layer 2 capability. For example, Ethernet 
interfaces and Wi-Fi interfaces will be autoconfigured as OSPFv3 
broadcast networks and Point-to-Point Protocol (PPP) interfaces 
will be autoconfigured as OSPFv3 Point-to-Point interfaces. Most 
extant OSPFv3 implementations do this already. autoconfigured 
operation over wireless networks requiring a point-to-multipoint 
(P2MP) topology and dynamic metrics based on wireless feedback is 
not within the scope of this document. However, 
autoconfiguration is not precluded in these environments. 


4. OSPFv3 interfaces MAY use an arbitrary HelloInterval and 
RouterDeadInterval as specified in Section 3. Of course, an 
identical HelloInterval and RouterDeadInterval will still be 
required to form an adjacency with an OSPFv3 router not 
supporting autoconfiguration [OSPFV3]. 


5. All OSPFv3 interfaces SHOULD be autoconfigured to use an 
Interface Instance ID of 0 that corresponds to the base IPv6 
unicast address family instance ID as defined in [OSPFV3-AF]. 
Similarly, if IPv4 unicast addresses are advertised in a separate 
autoconfigured OSPFv3 instance, the base IPv4 unicast address 
family instance ID value, i.e., 64, SHOULD be autoconfigured as 
the Interface Instance ID for all interfaces corresponding to the 
IPvA unicast OSPFv3 instance [OSPFV3-AF]. 
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Bis 


Bhs 


OSPFv3 HelloInterval/RouterDeadInterval Flexibility 


autoconfigured OSPFv3 routers will not require an identical 
HelloInterval and RouterDeadInterval to form adjacencies. Rather, 
the received HelloInterval will be ignored and the received 
RouterDeadInterval will be used to determine OSPFv3 liveliness with 
the sending router. In other words, the Neighbor Inactivity Timer 
(Section 10 of [OSPFV2]) for each neighbor will reflect that 
neighbor’s advertised RouterDeadInterval and MAY be different from 
other OSPFv3 routers on the link without impacting adjacency 
formation. A similar mechanism requiring additional signaling is 
proposed for all OSPFv2 and OSPFv3 routers [ASYNC-HELLO]. 


1. Wait Timer Reduction 


In many situations, autoconfigured OSPFv3 routers will be deployed in 
environments where back-to-back ethernet connections are utilized. 
When this is the case, an OSPFv3 broadcast interface will not come up 
until the other OSPFv3 router is connected, and the routers will wait 
RouterDeadInterval seconds before forming an adjacency [OSPFV2]. In 
order to reduce this delay, an autoconfigured OSPFv3 router MAY 
reduce the wait interval to a value no less than (HelloInterval + 1). 
Reducing the setting will slightly increase the likelihood of the 
Designated Router (DR) flapping but is preferable to the long 
adjacency formation delay. Note that this value is not included in 
OSPFv3 Hello packets and does not impact interoperability. 


OSPFv3 Minimal Authentication Configuration 


In many deployments, the requirement for OSPFv3 authentication 
overrides the goal of complete OSPFv3 autoconfiguration. Therefore, 
it is RECOMMENDED that OSPFv3 routers supporting this specification 
minimally offer an option to explicitly configure a single password 
for HMAC-SHA authentication as described in [OSPFV3-AUTH-TRAILER]. 
It is RECOMMENDED that the password be entered as ASCII hexadecimal 
digits and that 32 or more digits be accepted to facilitate a 
password with a high degree of entropy. When configured, the 
password will be used on all autoconfigured interfaces with the 
Security Association Identifier (SA ID) set to 1 and HMAC-SHA-256 
used as the authentication algorithm. 


OSPFv3 Router ID Selection 


An OSPFv3 router requires a unique Router ID within the OSPFv3 
routing domain for correct protocol operation. Existing Router ID 
selection algorithms (Appendix C.1 in [OSPFV2] and [OSPFV3]) are not 
viable since they are dependent on a unique IPv4 interface address 
that is not likely to be available in autoconfigured deployments. An 
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OSPFv3 router implementing this specification will select a Router ID 
that has a high probability of uniqueness. A pseudorandom number 
SHOULD be used for the OSPFv3 Router ID. The generation SHOULD be 
seeded with a variable that is likely to be unique in the applicable 
OSPFv3 router deployment. A good choice of seed would be some 
portion or hash of the Router-Hardware-Fingerprint as described in 
Section 7.2.2. 


Since there is a possibility of a Router ID collision, duplicate 
Router ID detection and resolution are required as described in 
Sections 7 and 7.3. OSPFv3 routers SHOULD maintain the last 
successfully chosen Router ID in nonvolatile storage to avoid 
collisions subsequent to when an autoconfigured OSPFv3 router is 
first added to the OSPFv3 routing domain. 


6. OSPFv3 Adjacency Formation 


Since OSPFv3 uses IPv6 link-local addresses for all protocol messages 
other than messages sent on virtual links (which are not applicable 
to autoconfiguration), OSPFv3 adjacency formation can proceed as soon 
as a Router ID has been selected and the IPv6 link-local address has 
completed Duplicate Address Detection (DAD) as specified in IPv6 
Stateless Address Autoconfiguration [SLAAC]. Otherwise, the only 
changes to the OSPFv3 base specification are supporting 
HelloInterval/RouterDeadInterval flexibility as described in 

Section 3 and duplicate Router ID detection and resolution as 
described in Sections 7 and 7.3. 


7. OSPEFv3 Duplicate Router ID Detection and Resolution 


There are two cases of duplicate OSPFv3 Router ID detection. One 
where the OSPFv3 router with the duplicate Router ID is directly 


connected and one where it is not. In both cases, the duplicate 
resolution is for one of the routers to select a new OSPFv3 Router 
ID. 


7.1. Duplicate Router ID Detection for Neighbors 


In this case, a duplicate Router ID is detected if any valid OSPFv3 
packet is received with the same OSPFv3 Router ID but a different 
IPv6 link-local source address. Once this occurs, the OSPFv3 router 
with the numerically smaller IPv6 link-local address will need to 
select a new Router ID as described in Section 7.3. Note that the 
fact that the OSPFv3 router is a neighbor on a non-virtual interface 
implies that the router is directly connected. An OSPFv3 router 
implementing this specification should ensure that the inadvertent 
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connection of multiple router interfaces to the same physical link is 
not misconstrued as detection of an OSPFv3 neighbor with a duplicate 
Router ID. 


7.2. Duplicate Router ID Detection for Non-neighbors 


OSPFv3 routers implementing autoconfiguration, as specified herein, 
MUST originate an Autoconfiguration (AC) Link State Advertisement 
(LSA) including the Router-Hardware-Fingerprint Type-Length-Value 
(TLV). The Router-Hardware-Fingerprint TLV contains a variable- 
length value that has a very high probability of uniquely identifying 
the advertising OSPFv3 router. An OSPFv3 router implementing this 
specification MUST detect received Autoconfiguration LSAs with its 
Router ID specified in the LSA header. LSAs received with the local 
OSPFv3 Router’s Router ID in the LSA header are perceived as self- 
originated (see Section 4.6 of [OSPFV3]). In these received 
Autoconfiguration LSAs, the Router-Hardware-Fingerprint TLV is 
compared against the OSPFv3 Router’s own router hardware fingerprint. 
If the fingerprints are not equal, there is a duplicate Router ID 
conflict and the OSPFv3 router with the numerically smaller router 
hardware fingerprint MUST select a new Router ID as described in 
Section 7.3. 


This new LSA is designated for information related to OSPFv3 
autoconfiguration and, in the future, could be used for other 
autoconfiguration information, e.g., global IPv6 prefixes. However, 
this is beyond the scope of this document. 


7.2.1. OSPFv3 Router Autoconfiguration LSA 


The OSPFv3 Autoconfiguration (AC) LSA has a function code of 15 and 
the S2/S1 bits set to 01 indicating Area Flooding Scope. The U bit 
will be set indicating that the OSPFv3 AC LSA should be flooded even 
if it is not understood. The Link State ID (LSID) value will be an 
integer index used to discriminate between multiple AC LSAs 
originated by the same OSPFv3 router. This specification only 
describes the contents of an AC LSA with an LSID of 0. 
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0 l 2 3 
(O U S ES E EE S R 28 O80 1 2 3A BO) 8 BOT 2-3 458. 67 e 90.1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| LS age |ıļolļ1] 15 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Link State ID | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Advertising Router | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
| LS sequence number | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
| LS checksum | Length | 
| 
| 


sls TLVs 


+ 
+ 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
-+ 


OSPFv3 Autoconfiguration (AC) LSA 


The format of the TLVs within the body of an AC LSA is the same as 
the format used by the Traffic Engineering Extensions to OSPFv2 [TE]. 
The LSA payload consists of one or more nested TLV triplets. The 
format of each TLV is: 


0 1 2 3 
O:1.2:734:5.6 Tg 9 OL 235-4? 5-6: OT 8 9:0-:1-2:374' 5:60:18. 9-0 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Type | Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Value... | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


TLV Format 


The Length field defines the length of the value portion in octets 
(thus a TLV with no value portion would have a length of 0). The TLV 
is padded to 4-octet alignment; padding is not included in the length 
field (so a 3-octet value would have a length of 3, but the total 
size of the TLV would be 8 octets). Nested TLVs are also 32-bit 
aligned. For example, a l-bvte value would have the length field set 
to 1, and 3 octets of padding would be added to the end of the value 
portion of the TLV. Unrecognized types are ignored. 


The new LSA is designated for information related to OSPFv3 


autoconfiguration and, in the future, can be used other 
autoconfiguration information. 
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7.2.2. Router-Hardware-Fingerprint TLV 


The Router-Hardware-Fingerprint TLV is the first TLV defined for the 
OSPFv3 Autoconfiguration (AC) LSA. It will have type 1 and MUST be 
advertised in the LSID OSPFv3 AC LSA with an LSID of 0. It SHOULD 
occur, at most, once and the first instance of the TLV will take 
precedence over subsequent TLV instances. The length of the Router- 
Hardware-Fingerprint is variable but must be 32 octets or greater. 
If the Router-Hardware-Fingerprint TLV is not present as the first 
TLV, the AC LSA is considered malformed and is ignored for the 
purposes of duplicate Router ID detection. Additionally, the event 
SHOULD be logged. 


The contents of the hardware fingerprint MUST have an extremely high 
probability of uniqueness. It SHOULD be constructed from the 
concatenation of a number of local values that themselves have a high 
likelihood of uniqueness, such as Media Access Control (MAC) 
addresses, CPU ID, or serial numbers. It is RECOMMENDED that one or 
more available universal tokens (e.g., IEEE 802 48-bit MAC addresses 
or IEEE EUI-64 Identifiers [EUI64]) associated with the OSPFv3 router 
be included in the hardware fingerprint. It MUST be based on 
hardware attributes that will not change across hard and soft 
restarts. 


0 il 2 3 
O:1.2734:5.6 T g F OL 23:41 5-6: 1-8 9:0:1-2:3:4'5:6: 1:28. 9:01 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| 1 | >32 | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Router Hardware Fingerprint 

o 
o 
o 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Router-Hardware-Fingerprint TLV Format 
7.3. Duplicate Router ID Resolution 


The OSPFv3 router selected to resolve the duplicate OSPFv3 Router ID 
condition must select a new OSPFv3 Router ID. The OSPFv3 router 
SHOULD reduce the possibility of a subsequent Router ID collision by 
checking the Link State Database (LSDB) for an OSPFv3 
Autoconfiguration LSA with the newly selected Router ID and a 
different Router-Hardware-Fingerprint. If one is detected, a new 
Router ID should be selected without going through the resolution 
process (Section 7). After selecting a new Router ID, all self- 
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originated LSAs MUST be reoriginated, and any OSPFv3 neighbor 
adjacencies MUST be reestablished. The OSPFv3 router retaining the 
Router ID causing the conflict will reoriginate or flush any stale 
self-originated LSAs as described in Section 13.4 of [OSPFV2]. 


7.4. Change to RFC 2328, Section 13.4 ("Receiving Self-Originated 
LSAs") 


RFC 2328 [OSPFV2], Section 13.4, describes the processing of received 
self-originated LSAs. If the received LSA doesn’t exist, the 
receiving router will flush it from the OSPF routing domain. If the 
LSA is newer than the version in the LSDB, the receiving router will 
originate a newer version by advancing the LSA sequence number and 
reoriginating. Since it is possible for an autoconfigured OSPFv3 
router to choose a duplicate OSPFv3 Router ID, OSPFv3 routers 
implementing this specification should detect when multiple instances 
of the same self-originated LSA are flushed or reoriginated since 
this is indicative of an OSPFv3 router with a duplicate Router ID in 
the OSPFv3 routing domain. When this condition is detected, the 
OSPFv3 router SHOULD delay self-originated LSA processing for LSAs 
that have recently been flushed or reoriginated. This specification 
recommends 10 seconds as the interval defining recent self-originated 
LSA processing and an exponential back-off of 1 to 8 seconds for the 
processing delay. This additional delay should allow for the 
mechanisms described in Section 7 to resolve the duplicate OSPFv3 
Router ID conflict. 


Since this mechanism is useful in mitigating the flooding overhead 
associated with the inadvertent or malicious introduction of an 
OSPFv3 router with a duplicate Router ID into an OSPFv3 routing 
domain, it MAY be deployed outside of autoconfigured deployments. 
The detection of a self-originated LSA that is being repeatedly 
reoriginated or flushed SHOULD be logged. 


8. Security Considerations 


The goals of security and complete OSPFv3 autoconfiguration are 
somewhat contradictory. When no explicit security configuration 
takes place, autoconfiguration implies that additional devices placed 
in the network are automatically adopted as a part of the network. 
However, autoconfiguration can also be combined with password 
configuration (see Section 4) or future extensions for automatic 
pairing between devices. These mechanisms can help provide an 
automatically configured, securely routed network. 


In deployments where a different authentication algorithm or 
encryption is required (or different per-interface keys are 
required), OSPFv3 IPsec [OSPFV3-IPSEC] or alternate OSPFv3 
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10. 


Authentication Trailer [OSPFV3-AUTH-TRAILER] algorithms MAY be used 
at the expense of additional configuration. The configuration and 
operational description of such deployments are beyond the scope of 
this document. However, a deployment could always revert to explicit 
configuration as described in Section 9 for features such as IPsec, 
per-interface keys, or alternate authentication algorithms. 


The introduction, either malicious or accidental, of an OSPFv3 router 
with a duplicate Router ID is an attack point for OSPFv3 routing 
domains. This is due to the fact that OSPFv3 routers will interpret 
LSAs advertised by the router with the same Router ID as self- 
originated LSAs and attempt to flush them from the routing domain. 
The mechanisms in Section 7.4 will mitigate the effects of 
duplication. 


Management Considerations 


It is RECOMMENDED that OSPFv3 routers supporting this specification 
also support explicit configuration of OSPFv3 parameters as specified 


in Appendix C of [OSPFV3]. This would allow explicit override of 
autoconfigured parameters in situations where it is required (e.g., 
if the deployment requires multiple OSPFv3 areas). This is in 


addition to the authentication key configuration recommended in 
Section 4. Additionally, it is RECOMMENDED that OSPFv3 routers 
supporting this specification allow autoconfiguration to be 
completely disabled. 


Since there is a small possibility of OSPFv3 Router ID collisions, 
manual configuration of OSPFv3 Router IDs is RECOMMENDED in OSPFv3 
routing domains where route convergence due to a Router ID change is 
intolerable. 


OSPFv3 routers supporting this specification MUST augment mechanisms 
for displaying or otherwise conveying OSPFv3 operational state to 
indicate whether or not the OSPFv3 router was autoconfigured and 
whether or not its OSPFv3 interfaces have been autoconfigured. 


IANA Considerations 


This specification defines an OSPFv3 LSA Type for the OSPFv3 
Autoconfiguration (AC) LSA, as described in Section 7.2.1. The value 
15 has been allocated from the existing "OSPFv3 LSA Function Codes" 
registry for the OSPFv3 Autoconfiguration (AC) LSA. 
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This specification also creates a registry for OSPFv3 
Autoconfiguration (AC) LSA TLVs. This registry has been placed in 
the existing OSPFv3 IANA registry, and new values will be allocated 
via IETF Review or, under exceptional circumstances, IESG Approval. 
(TANA-GUIDELINESJ 


Three initial values are allocated: 
o 0 is marked as Reserved. 
o l is Router-Hardware-Fingerprint TLV (Section 7.2.2). 


o 65535 is an Autoconfiguration-Experiment-TLV, a common value that 
can be used for experimental purposes. 
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